Skip to content

Use at least two segments so a single-segment store keeps its data - #18

Open
mclueppers wants to merge 1 commit into
attermann:masterfrom
dobrevit:fix/single-segment-store
Open

mclueppers wants to merge 1 commit into
attermann:masterfrom
dobrevit:fix/single-segment-store

Conversation

@mclueppers

Copy link
Copy Markdown
Contributor

Problem

A FileStore initialised with segment_count == 1 loses every record written after its first compaction. Compaction fills seg0, and the rotation and threshold paths then write to seg1, which lies outside the range that compaction and index rebuilds scan. Fixes #.

Solution

init() raises a segment_count below 2 to 2, with a log line. That covers a count set through the constructor, through init() or through USTORE_DEFAULT_SEGMENT_COUNT. Two is the real minimum of the design: one segment holds the compacted data and one takes new writes. I chose raising the value over refusing to init, so existing callers keep working; if you would rather init() fail, it's a one-line change.

Compatibility

  • No change to the on-disk format. A store created with one segment is now opened as a two-segment store, so its seg1 falls inside the scanned range. I haven't tested whether records already stranded there are recovered on upgrade.
  • Crash safety unchanged: only the in-memory segment count changes
  • No breaking public API change
  • Still header-only, C++14, no new dependencies
  • No board- or variant-specific code

Testing

  • native: pio test -e native, 113/113. The new test_file_store_single_segment_count_keeps_data fails on master (Expected 10 Was 1) and passes on the branch.
  • ESP32 / nRF52: not run on hardware; this is a host-reproducible logic change with no adapter code.

Docs

  • CHANGELOG (Unreleased → Fixed) and the user guide's segment_count note

Closes #17.

Compaction writes the live records into seg0, and both the rotation and the
threshold paths then move new writes to seg1. A store initialised with
segment_count 1 therefore writes everything after its first compaction into
seg1, outside the range that compaction and index rebuilds scan. That file
grows without bound and its records are dropped on the next reload. This
predates the recent compaction changes; 0.1.7 behaves the same.

init() now raises a segment_count below 2 to 2, which covers counts set
through the constructor, init() and USTORE_DEFAULT_SEGMENT_COUNT alike.

Adds test_file_store_single_segment_count_keeps_data.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FileStore with segment_count 1 loses every record written after its first compaction

1 participant